SGI's proprietary IRIS GL, while not an X server extension like the first two examples, does handle the broader problem of maintaining interactivity for simultaneous 3D rendering from multiple programs. IBM also supports a version of IRIS GL [6].
In IRIX 4.0. x as well as IRIX 5. x, IRIS GL programs cooperate with the SGI X server for validation of rendering resources but render directly to the hardware. Operating system support, window system support, and hardware support all combine to provide virtualized direct access rendering. This system support is discussed in the next section.
Our multi-rendering scheme uses much of the same system support originally implemented for IRIS GL, though a good deal of the support needed to be enhanced to support new capabilities allowed by OpenGL such as binding multiple renderers to a single window.
Even though IRIS GL rendering is primarily designed for local use where the graphics program directly accesses the graphics hardware, a network extensible component known as DGL allows IRIS GL programs to run over the network connecting to an SGI workstation supporting IRIS GL. In this case, a program known as dgld runs as a proxy for the remote program. The dgld is connected to the remote program via a byte-stream network connection. DGL protocol is sent across the connection to the dgld. IRIS GL commands which are normally sent directly to the hardware are encoded using the DGL protocol and sent to the dgld proxy to be executed. A separate dgld runs for every remote IRIS GL program using DGL.
In some respects, this scheme is very similar to multi-rendering except that the proxy executes outside of the X server's address space and a totally separate protocol is used for IRIS GL requests. The DGL proxy scheme has a potential reliability advantage over multi-rendering since bugs or crashes of the dgld do not affect the integrity of the X server. A multi-rendering approach requires the rendering processes to maintain higher standards of reliability than a dgld proxy requires.
The proxy scheme is inappropriate for OpenGL and PEX because both OpenGL's GLX protocol and the PEX protocol are X extension protocols. Like all X extensions, the GLX and PEX protocols are embedded in the X11 protocol stream. Since the X server must read the OpenGL and PEX requests, it is most efficient for the rendering processes to execute in the same address space as the X server so that requests can be communicated to the rendering threads via shared memory.